I am already using the same app in cf without this problem. What has changed in cf? Before 2 or 3 weeks it still worked.
You must have upgraded to Java Build Pack v4. With JBP v3, you could push apps with smaller amounts of memory, but app that were pushed with that version of the buildpack and small memory limits were also very prone to crashing. The reason for this is because JBP v3 did not take into account all of the regions of memory used by the JVM when the JBP did it's calculations, so while it would let your app start, the app could still go over it's memory limit later. The way JBP v4 calculates memory is more accurate now, and take all of the JVM's memory regions into account.
The net result is that with JBP v4 apps that run with less than 1G of RAM can see the following error at staging, and apps that run with 512M or less will almost certainly see this error at staging:
ERR Cannot calculate JVM memory configuration: There is insufficient memory remaining for XXXX
However, Java apps that to do successfully stage are significantly less likely to crash.
https://discuss.pivotal.io/hc/en-us/articles/115011717548-Insufficient-memory-when-using-Java-Buildpack-4-0-
So does this mean you can't run a Java app with less than 1G of RAM? No. You can, but it's going to require some tuning. Here is a list of some things you can tune to save some memory.
Thread count. The JBP assumes your application will run with 250 threads. This is pretty common for a Web application, which will have about 50 for Tomcat's internal stuff and 200 for request handling. You can lower this value, but you need to make sure your app does not exceed whatever number of threads you set, otherwise your app can crash. For you, this would adjusting Tomcat's configuration through Spring Boot.
Example of lower thread count for the JBP:
cf set-env my-application JBP_CONFIG_OPEN_JDK_JRE '{ memory_calculator: { stack_threads: 50 } }'
Exaple of lower thread count in Spring Boot application.properties:
server.tomcat.max-threads=25
Note: this is just the request processing threads. Tomcat itself has threads and your app may create threads too. You should really look in a thread dump or JVisualVM to see how many threads your app requires (i.e. measure, don't guess)
Thread stack size (-Xss). This is a value passed through to the JVM which controls how much memory is required per thread. It defaults to 1M, which is very high. In most cases, you can safely lower it to 160K, which is the minimum allowed with Java 8. If you have 250 threads and make this change, you'll save (1M * 250) - (160K - 250) = 211M of RAM.
Note: If you lower the thread stack size too much, you'll see StackOverflow Exceptions in your app. If that happens, keep calm and raise the value up until they go away.
Lower the Reserved Code Cache. This is where the JVM caches JIT'd code. It defaults to 240M. You can lower this value, but do so with caution as this can absolutely impact performance. You can also see errors at runtime if this value is not high enough.
Again, it's better to measure what your app requires rather than guess. You should be able to measure by using the JVM's NMT.
You can manually adjust the other areas of memory used by the JVM like Heap & Metaspace. With JBP v4, it's as easy as setting the JAVA_OPTS environment variable with cf set-env or in your manifest.yml file. Obviously, if you lower these values you need to be careful that you don't go too low, in which case you'll end up with OutOfMemoryErrors.
Note: If you leave one region unset, like heap or metaspace the JBP will smartly calculate it with whatever is remaining after your manual customizations.
Hope that helps!
