Thanks for the links. It's good to see that there is ongoing development to improve the situation.
It would still be nice to be have a Spring Boot app work on a 512MB container but even pretty simple ones don't seem to.
Re:Debunking the Java Performance Myth
by jacques_chester on Monday October 23, 2017 @09:18PM
(#15538424)
There must be more we can do, but I honestly don't feel qualified to say what it is. Ben Hale is the fellow to ask, he's the JBP maintainer.
I've recently toyed with the idea of taking libbuildpack and OpenJ9 and just ... seeing what I can do. But I'm ill-qualified to tinker with either and it's in the pile of fifty kerjillion other sideprojects I want to do.
A long-standing difficulty with the Java Buildpack was working out how much memory to give it -- the Garden container engine is particularly ruthless to any process going above the allocated memory limit. I believe it got a lot of attention in v4 (edit: see [0] and [1]).
My personal pet peeve is that the memory quota is identical for staging and runtime. Which means that memory-intensive staging operations force you to have wasteful runtime memory allocations. I mostly noticed this when using Rails apps that pull in Nokogiri -- it gets compiled during staging and often that causes a lot of memory usage.
Disclosure: I work for Pivotal, we do the majority of Cloud Foundry engineering. We also sponsor Spring.
[0] https://www.cloudfoundry.org/just-released-java-buildpack-4-...
[1] https://github.com/cloudfoundry/java-buildpack-memory-calcul...