Java-buildpack: Cannot start java app with buildpack version b08a692

Confirmed. We are also seeing this issue,

Please could you post the precise failure from the application logs.

The Java buildpack memory calculator was upgraded to v3 by commit b08a692. v3 respects the OpenJDK defaults for reserved code cache, which on Java 8 is 240 megs. It seems likely that this is what is causing the application to fail to start. You can override the value used by the memory calculator as in the following example:

cf set-env app-name JAVA_OPTS '-XX:ReservedCodeCacheSize=64m'

but you'll have to pick a suitable size because if you make it too small, the application's CPU consumption could become high.

Due to commit https://github.com/cloudfoundry/java-buildpack/commit/b08a69221a9ecfa61a9bfd568639f891b9313a19, our applications also failed to load/crashed with OutOfMemory:Metaspace. It seems that the memory calculator (v3+) no longer uses ~10% memory for the metaspace but sets the maximum metaspace size to ~56m.

Workaround: Use release v3.14 (https://github.com/cloudfoundry/java-buildpack.git#v3.14) instead of latest.

We're seeing similar issues, but caused by insufficient CompressedClassSpace - it's not too far off, giving us 8385K, while we actually need more like 8704K.

@markbigler The v3 memory calculator estimates the metaspace consumption based on the number of class files in the application. When this is insufficient, you can set the metaspace limit using, for example:

cf set-env app-name JAVA_OPTS '-XX:MaxMetaspaceSize=100m'

@ipsi Similarly for compressed class space. You can set it using, for example:

cf set-env app-name JAVA_OPTS '-XX:CompressedClassSpaceSize=20m'

same issue here, getting outofmemory error

Same issue here. Using the old version of the buildpack temporarily solved it:

cf push -b https://github.com/cloudfoundry/java-buildpack.git\#v3.12

StackOverflow question to this topic: http://stackoverflow.com/questions/42576613/java-spring-application-cannot-start-up-on-cloudfoundry-outofmemoryerror-compre

thanks that worked!

We are seeing similar issues here, the class calculation will fail for customers using our agent since our javaagent is a native binary for performance reasons. I'd like to see the calculator be a bit less aggressive or some instructions on manipulating the calculator's functionality via an extension. Having to tell all of our customers to manually define additional java options is sub-optimal...

@akirasoft Thanks for describing your use case. How would you like to influence the calculator's behaviour? For example, would it make sense to adjust the estimate of the number of loaded classes (that the Java buildpack passes to the memory calculator) and then let the calculator derives memory settings based on the new estimate? If so, does your javaagent add a fixed number of classes or does the number added depend (linearly?) on the number of classes loaded by the application?

@glyn our footprint will be some additional flat space to hold our agent and then a little bit more space proportionally based on the classes than your calculator is expecting, say 1-3% additional, if I were to guess. Generally speaking it looks to me like the calculator is just a bit too aggressive based on other comments here. Everything was working great for the past year or so with the previous calculator.

Same here. This application (https://github.com/EuregJUG-Maas-Rhine/site, Spring Boot) doesn't start up any more (CompressedClassSpace).

I also have the same problem. Rolling back to an older version fixed it for me as well.

Same problem with my apps as well. Rolling back to v3.13

We're also seeing OutOfMemoryErrors:

2017-03-06T09:20:39.44+0900 [App/0] OUT # java.lang.OutOfMemoryError: Compressed class space

maybe the v3 heuristics need tuning

@akirasoft "some additional flat space" will likely be split across heap, metaspace, and compressed class space (or permgen in Java 7) and may possibly even affect reserved code cache and direct memory consumption, so it's not sufficient to add a constant to a single formula to take account of an agent's needs. Is it possible to frame the agent's "flat space" consumption in terms of an equivalent number of loaded classes? See the design of memory calculator v3 for details of how the calculation came about.

We are in the process of making the memory calculator allocate more metaspace and compressed class space. See commit c9867a6 for details.

Memory calculator v3.2.0.RELEASE is available. Please retry your application pushes and see if they now work.

@glyn we spoke via Slack but everything looks much better now, thanks for the fix!

I have reverted back to buildpack v3.12, it works well.

Since it has been referred to the more accurate issue #391, I close this issue for now.

Thanks everyone's help.